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(57) Abstract: There is described a system which, in a voice over IP radiotelecommunications system, allows a mobile siation to 
make an emergency call, even though other calls would not be allowed at that time. The mobile station includes an emergency call 
indication in the session activation request, and this is recognised by the network nodes, which then allow call set up. 
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SYSTEM AND METHOD FOR EMERGENCY CALL HANDLING IN A MOBILE PACKET SWITCHED 
NETWORK 

TECHNICAL FIELD OF THE INVENTION 

This invention relates to a telecommunications 
system,, and to a method of operation thereof. More 
5 particularly, the invention relates to a 

telecommunications network using Internet Protocol 
(IP) , and specifically to a system for handling 
emergency calls in such a network. 
BACKGROUND OF THE INVENTION 
10 In mobile communication systems, there are 

situations in which a call, request may not be allowed. 
For example the user may not have paid a bill, or the. 
mobile system may have no information at all about the 
user, or there may be congestion on the network, or the 
'15 mobile phone may be reported stolen. 

In the GSM system, emergency calls may be allowed 
even when one of these factors apply. 

It is expected that 3 rd generation (3G) mobile 
phones will allow voice over IP. That is, the Internet 
20 Protocol (IP) will be' used for the whole call from the 

mobile phone to the network gateway which is the 
connection to the public switched telephone network 
(PSTN) which includes the emergency services operator. 
Therefore, all calls will send the voice signals as 
25 packet data, rather than as circuit .switched data. 

The document "GSM on the Net", by Granberg, 
Ericsson Review No. 4, 1998 pages 184-191, describes a 
voice over IP system, based on the recommendation ITU 
H.323. The H.323 protocol separates call control 
30 (signalling in the call setup phase) from connection 

control (the actual data flows) . 

■ However, it provides no mechanism to allow for 
special treatment of emergency calls. 
SUMMARY OF THE INVENTION 
35 % The present invention is concerned with allowing 
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special treatment of emergency calls, so that such a 
call can be successful even though another voice call 
would not be allowed. 

According to one aspect of the invention, a mobile 
communication device analyses a dialled number and, in 
the case of an emergency call, sends a session 
activation request which includes an emergency call 
indication . 

According to another aspect of the invention, a 
-node in a packet data communication network detects an 
emergency call indication in a session activation 
request, and allows call setup, even though a call 
without such an indication would fail. 

According to another aspect of the invention, 
BRIEF DESCRIPTION OF DRAWINGS 

Figure 1 is a diagram illustrating message flows 
during call setup in accordance with the invention. 

Figure 2 is a flow chart showing a method carried 
out in a mobile phone in accordance with the invention. 

Figure 3 is a schematic representation of a mobile 
phone in accordance with the invention. 

Figure 4 is a diagram illustrating message flows 
during call setup in accordance with a second 
embodiment of the invention. 
5 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

In accordance with the invention, when a mobile 
phone wishes to place an emergency call, it sets a 
special emergency call indication when requesting 
mobile system and radio resources. 
0 Figure 1 shows the network components required to 

connect a 3 rd generation mobile phone to an emergency 
services operator. A radio network controller (RNC) 
controls the air interface with a mobile station 10, 
and operates in the Universal Mobile Telephony System 
5 - (UMTS) or using Wideband Code Division Multiple Access 
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(WCDMA) . The network operates using the General Packet 
Radio System (GPRS) , and includes a Serving GPRS 
Service Node (SGSN) and a Gateway GPRS Service Node 
(GGSN) . The GGSN is connected to a call server in the 
IP multimedia domain, and this is further connected to 
a gateway, which is connected to the public telephone 
network, operating for example as a Public Switched 
Telephone Network (PSTN) or Integrated Services Digital 
Network (ISDN) system. The emergency services operator 
is connected to the public telephone ' net work . 

The call setup procedure is also shown in Figure 
1, while Figure 2 shows the procedure in the phone, and 
Figure 3 is a representation of a phone 10. The 
procedure is described further with reference to the 
Session Initiation Protocol (SIP) , described in IETF 
document IETF/RFC 2543. This protocol is part of the 
IETF multimedia data and control architecture, and can 
be used to set up calls between parties. 

As shown in Figure 1, a user enters a dialled 
number, for example via a keypad 12, which is sent to a 
controller 14, which then forms a message to be sent 
via transceiver circuitry 16 through an. antenna 18. 

In the controller 14, the dialled number is. 
received (step 20 in Figure 2) , and the controller 
recognises from the dialled digits (for example, the 
numbers 112, 911 or 999) , that the call is an emergency 
call. The session activation request which is then 
sent (step 24, and also see Figure 1) is then handled 
accordingly. 

The mobile phone has to activate a packet (IP) 
data communication session with the mobile GPRS system 
over, the air interface. A first PDP activation 
(Activate PDP Context Request, according to the GSM 
recommendation 24.008) is -sent from the mobile station 
.-to the SGSN to get a. signalling radio bearer. When 
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this has been obtained, the mobile station sends a 
' second PDP activation to the SGSN, stipulating the need 
for a voice communication, allowing the user to speak 
to an operator at an emergency centre. The second PDP 
activation includes the requested bandwidth, delay and 
other quality of service parameters. These two radio 
bearers remain in parallel until the call, is dropped. 

In- the illustrated embodiment of the invention, 
the two activation messages each include an indication 
that this is an emergency call. In the context of the 
GSM recommendation 24.008, the emergency indicator 
-could for example be set by setting the Access Point 
Name (APN) to u EMERGENCY " , Or something similar. 

Thus, in more detail, the first session activation 
request is received by the 3G GPRS SGSN element. The 
SGSN recognises the received emergency call indication, 
and the SGSN will then not stop the call setup process, 
even if it would normally fail, for example because it 
cannot obtain user profile data or if unsuccessful 
authentication occurs. 

The SGSN will send a Create PDP context request to 
the GGSN of the same network as the SGSN, to create a 
packet session with it. The context request will 
contain the special indication about an emergency call, 
received from the mobile phone as described above. 
This opens a communication path between the SGSN and 
the GGSN for this particular emergency call. 

Since the GGSN has received the emergency call 
indication from the SGSN, the GGSN will determine the 
identity of the locally geographical VoIP call server 
that should receive forthcoming call control signals 
from- the mobile phone. This can be done by software in 
the GGSN. This has the advantage that the call is 
routed out from the mobile system and to the public 
..network emergency centre as fast as possible. This 
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avoids the possibility that the call could be routed to 
the call server belonging to the home network of the 
user. If the user is roaming, this could conceivably 
be in another country. 
5 This call server identity is thereafter returned 

by the GGSN to the. SGSN in the acknowledgement message 
which relates to the first activation message. The 
call server identity can be an IP address in 
conventional format. 
10 The SGSN then returns the call server identity 

back to the mobile phone, for example in the 
acknowledgement signal to the first Activate PDP 
context request message. 

When the mobile phone gets a successful session 
15 activation acknowledgement from the mobile system, the 

mobile phone can start the voice over IP (VoIP) related 
call control signalling over the session. In this 
described embodiment, this call control signalling is . 
as described in the IETF Session Initiation Protocol. 
20 (SIP) . The first signal, that is, the INVITE signal in 

SIP, will include the VoIP call server identity 
determined by the GGSN and received from the SGSN. 
When the mobile terminal receives the call server 
identity in the format of an IP address, the mobile 
25 terminal should set this address in the IP packet 

header "destination address" field at all times when 
sending SIP messages, including the INVITE message. In 
this way, network routers will route IP packets that 
are carrying such SIP messages, directed to the call 
30 server, correctly to the call server. 

The call server can also typically be the same as 
handling all the normal VoIP calls as well. The 
initial message, for example the SIP INVITE message, 
includes an emergency indication as well, either the 
35 -number dialled by the user e.g. 112 in a 3G UMTS 
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European system or 911 in a 3G UMTS North America 
system, or a separate emergency indication. 
Alternatively, a new message could be defined, for 
example a SIP EMERGENCY INVITE message. Including the 
emergency indication avoids the possibility that the 
call server could treat the call as a normal voice 
call, with the possibility that it could stop the call 
process in the event of a failure to continue. 

The call server then places an ISUP call to the 
appropriate PSTN signalling/media gateway for the 
emergency services operator using ISUP/IP, which routes 
the call using I SUP/SS7 to the operator. Then, as is 
•conventional, a ringing response is sent using ISUP to 
the .gateway, and using SIP to the call server and then 
to the mobile station. The response includes the 
address of the gateway. 

This can then be. used by the mobile station to 
create the required voice bearers to carry speech to 
the emergency services operator with the desired 
parameters, using the gateway address so that speech 
packets can reach the gateway. Thus, the mobile 
terminal sends a second Activate PDP Context request 
message, including an emergency indication, . to the 
SGSN, which sets up a radio access bearer with the 
mobile terminal > and also sends a Create PDP Context 
request to the GGSN . 

The GGSN responds to this message, and the SGSN 
sends an Activate PDO Context accepr message to the 
mobile terminal, after which a speech path is 
established between the mobile terminal and the 
emergency services operator. 

Figure 4 illustrates a second call setup process 
according to the invention. 

In the same way as Figure 1, Figure 4 also shows 
the network components required to. connect a 3 rd 
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generation mobile phone to an emergency services 
operator, namely a radio network controller (RNC) 
controlling the air interface with a mobile station 10. 
The network operates using the GPRS system, and 
includes a SGSN and a GGSN . The GGSN is connected to a 
call server in the IP multimedia domain, and this is 
further connected to a gateway, which is connected to 
the public telephone network, operating for example as 
a PSTN or ISDN system. The emergency services operator 
is connected to the public telephone network. 

Figure 4 shows the set up of an emergency call 
from a mobile station, when the mobile station does not 
contain a Subscriber Identity Module (SIM) card. In 
that case, it is conventionally not possible to 
initiate a call. 

As in the procedure described with reference to 
Figure 1, the mobile phone has to activate a packet 
(IP) data communication session with the mobile GPRS 
system over the air interface. In this case, when the 
mobile phone is without a SIM, it is permitted to form 
a limited attach. Thus, the mobile station sends an 
attach request via the RNC to the SGSN. In the attach 
request, the International Mobile Station Equipment 
Identity (IMEI) is transmitted as the mobile identity, 
and there is no Routing Area Indentif ication (RAI ) or 
Ciphering Key Sequence Number (CKSN) . An alternative 
is that the attach request should be allowed to be sent 
without any mobile identity. 

In this embodiment of the invention, the only 
service allowed after formation of a limited attach is 
an emergency call. Therefore, the receipt by the SGSN 
of an attach request with the IMEI as the only 
identifier is a preliminary indication that an 
emergency call is required. 

The formation of a limited attach is allowed in 
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some . si tuations where a normal attach would not be 
allowed, including in this case where no SIM is 
available. A normal attach should be used if possible. 
In the procedure illustrated in Figure 4, the SGSN 
accepts the formation of the limited attach, and 
returns an attach accept message to the mobile station, 
with a Temporary Mobile Station Identifier (P-TMSI) , 
and a Random Access Identifier (RAI) . 

The SGSN does not need to contact the Home ' 
Location Register (HLR) of the mobile station 
subscriber. Moreover, the SGSN does not perform any 
authentication or ciphering. 

Thereafter, a request is sent from the mobile 
station to the SGSN to get a signalling radio bearer. 
When this has been obtained, the mobile station sends a 
second PDP activation request to the SGSN, stipulating 
the need for a voice communication, allowing the user 
to speak to an operator at an emergency centre. The 
second PDP activation includes the requested bandwidth, 
delay. and other quality of service parameters. These 
two radio bearers remain in parallel until the call is 
dropped. 

Preferably, the two activation messages each 
include an indication that this is an emergency call. 
In the context of the GSM recommendation 24.008, the 
emergency indicator could for example be set by setting 
the Access Point Name (APN) to u EMERGENCY " , Or 
something similar. 

Thus, in more detail, the first session activation 
request is received by the 3GGPRS SGSN element. The 
SGSN recognises the received emergency call indication, 
and. the SGSN will then not stop the call setup process, 
even if it would normally fail, for example because it 
cannot obtain user profile data or if unsuccessful 
..authentication occurs. 
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The SGSN will send a Create PDP context request to 
the GGSN of the same network as the SGSN, to create a 
packet session with' it. The context request will 
contain the special indication about an emergency call, 
5 received from the mobile phone as described above. 

This opens a communication path between the SGSN and 
the GGSN for this particular emergency call. 

Since the GGSN has received the emergency call 
indication from the SGSN, the GGSN will determine the 
10 identity of the locally geographical VoIP call server 

that should receive forthcoming call control signals 
from the mobile phone. This can be done by software in 
the GGSN. This has the advantage that the call is 
routed out from the mobile system and to the public 
15 network emergency centre as fast as possible. This 

avoids the possibility that . the call could be routed to 
the call server belonging to the home network of the 
user. If the user is roaming, this could conceivably 
be in another country. 
20 This call server identity is thereafter returned 

by the GGSN to the SGSN in the acknowledgement message 
which relates to the first activation message. The 
call server identity can be an IP address in 
conventional format. 
25 The SGSN then returns the call server identity 

back to the mobile phone, for example in the 
acknowledgement signal to the first Activate PDP 
context request message. 

When the mobile phone gets a successful session 
30 activation acknowledgement from the mobile system, the 

mobile phone can start the voice over IP (VoIP) related 
call, control signalling over the session. In this 
described embodiment, this call control signalling is 
as described in the IETF Session Initiation Protocol 
35 — (SIP) . The first signal, that is, the INVITE signal in 
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SIP, will include the VoIP call server identity 

determined by the GGSN and received from the SGSN . 

When the mobile terminal receives the call server 

identity in the format of an IP address, the mobile 

5 terminal should set this address in the IP packet 

header "destination address" field at all times, when 

sending SIP messages, including the INVITE message. In 

this way, network routers will route IP packets that 

are carrying such SIP messages, directed to the call 

10 server, correctly to the call server. 

The call server can also typically be the same as 

handling all the normal VoIP calls as well . The 

initial message, for example the SIP. INVITE message, 

includes an emergency indication as well, either the 

15 number dialled by the user e.g. 112 in a 3G UMTS 

» 

European system or 911 in a 3G UMTS North America 
system, or a separate emergency indication. 
Alternatively, a new message could be defined, for 
example a SIP EMERGENCY INVITE message. Including the 

20 emergency indication avoids the possibility that the 

call server could treat the call as a normal voice 
call, with the possibility that it could stop the call 
process in the event of a failure to continue. 

The call server then places an ISUP call to the 

25 appropriate PSTN signalling/media gateway for the 

emergency services operator using ISUP/IP, which routes 
the call using ISUP/SS7 to the operator. Then, as is 
conventional, a ringing response is sent using ISUP to 
the gateway, and using SIP to the call server and then 

30 to the mobile station. The response includes the 

address of the gateway. 

- This can then be used by the mobile station to 
create the required voice bearers to carry speech to 
the emergency services operator with the desired 

35 ^parameters; using the gateway address so that speech 
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packets can reach the gateway. Thus, the mobile 
terminal sends a second Activate PDP Context request 
message, including an emergency indication, to the 
SGSN, which sets up a radio access bearer with the 
5 mobile terminal, and also sends a Create PDP Context 

request to the GGSN . 

The GGSN responds to this message, and the SGSN 
sends an Activate PDO Context accepr message to the 
mobile terminal, after which a speech path is 
10 established between the mobile terminal and the 

emergency services operator. 

It should be noted that, although the invention 
has been described with particular reference to a GPRS 
based mobile telephone system using the IETF SIP,, it is 
15 applicable to any mobile communication system, which 

offers real-time packet (IP) data communication, with 
any type of call control protocol, including for 
example ITU-T H.323. 

There is thus described a method which allows an 
20 emergency call to be placed even when other calls would 

not be allowed. 



CLAIMS 

1. A mobile communications device, capable of 
operating in a packet data communications network, the 
device comprising: 

means for analysing a dialled number, 
the device being adapted, in the event that a 
dialled number is indicative of an emergency call, to 
send a session activation request which includes an 
emergency call indication. 

2. A mobile communications device- as claimed in 
claim 1, the device being adapted to send the session 
activation request, in the event that a dialled number 
is indicative of an emergency call, even if the device 
has no SIM. 

3. A method of handling an emergency call in a 
mobile device capable of operating in a packet data 
communication network, the method comprising: 

analysing a dialled number; and 
if the dialled number is indicative of an 
emergency call/ sending a session activation request 
which includes an emergency call indication. 

4. A method as claimed in claim 3, comprising 
sending the session activation request if the dialled 
number is indicative of an emergency call, even if the 
mobile device has no SIM. 

5 . A network node for use in a pocket data 
communications network, the node comprising means for 
detecting an emergency call indication in a received 
session activation request, and being adapted,, in the 
event that an emergency call indication is detected, to 
set up a call even if normal call setup criteria are 
not .met . 

6 . A node as claimed in claim 5 , wherein the 
mode is a SGSN element. 

7. A node as claimed in claim 6, wherein the 
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node is adapted, in the event that an emergency call 
indication is detected; to set up a call even if the 
received session activation request includes no mobile 
station identifier . 
5 8. A node as claimed in claim 6, adapted, in the 

event that an emergency call indication is detected, to 
create a packet session with a GGSN, including a 
further emergency call indication. 

9. A node as claimed in claim 5, wherein the 
10 mode is a GGSN element. 

10. A node as claimed in claim 7, adapted, in the 
event that an emergency call is detected, to return a 
message indicating a call server local to a calling 
device. 

15 11. A method of operation of a node in a packet 

data communications network, the method comprising: 

detecting an emergency call indication in a 
received session activation request, and 

if an emergency call indication is detected, 
20 setting up a call even if normal call setup criteria 

are not met . 

12. A method as claimed in claim 11, wherein the 
mode is a SGSN element, and the method further 
comprises : 

25 if an emergency call indication is detected, 

creating a packet session with a GGSN, including a 
further emergency call indication. 

13. A method as claimed in claim 11, wherein the 
mode is a SGSN element, and the method further 

30 comprises, in the event that an emergency call 

indication is detected, setting up a call even if the 
received session activation request includes no mobile 
station identifier . 

14. A method as claimed in claim 11, wherein the 
35 mode is a GGSN element, and the method further 
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comprises : 

if an emergency call indication is detected, 
returning a message indicating a call server local to a 
calling device. 
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